Using Flex 4

ProductAbstractFactory ConcreteProductConcreteFactoryAbstractClientManager ModuleApplication 145USING FLEX 4Application architecture Last updated 11/5/2010Module domainsBy default, a module is loaded into a child domain of the current application domain. You can specify a differentapplication domain by using the applicationDomain property of the ModuleLoader class. Because a module is loaded into a child domain, it owns class definitions that are not in the main application’s domain.For example, the first module to load the PopUpManager class becomes the owner of the PopUpManager class for theentire application because it registers the manager with the SingletonManager. If another module later tries to use thePopUpManager, Adobe ® Flash® Player throws an exception. The solution is to ensure that managers such as PopUpManager and DragManager and any other shared services aredefined by the main application (or loaded late into the shell’s application domain). When you promote one of thoseclasses to the shell, the class can then be used by all modules. Typically, this is done by adding the following to a scriptblock: import mx.managers.PopUpManager;import mx.managers.DragManager;private var popUpManager:PopUpManager;private var dragManager:DragManager; This technique also applies to components. The module that first uses the component owns that component’s classdefinition in its domain. As a result, if another module tries to use a component that has already been used by anothermodule, its definition will not match the existing definition. To avoid a mismatch of component definitions, create aninstance of the component in the main application. The result is that the definition of the component is owned by themain application and can be used by modules in any child domain. By default, modules do not share the main application’s StyleManager, however. They have their own instances of theIStyleManager2 class. As a result, modules can define their own styles. For example, style properties set on a Buttoncontrol in one module are not applied to the Button control in another module or to the main application. Because a module must be in the same security domain as the application (SWF) that loads it, when you’re usingmodules in an AIR application any module SWF must be located in the same directory as the main application SWFor one of its subdirectories, which ensures that like the main application SWF, the module SWF is in the AIRapplication security sandbox. One way to verify this is to ensure that a relative URL for the module’s location doesn’trequire "../" ("up one level") notation to navigate outside the application directory or one of its subdirectories. For more information about application domains, see “Developing and loading sub-applications” on page 179. Module applicationsTo create a modular application, you create separate classes for each module, and an application that loads themodules. Adobe® Flash® BuilderTM provides some mechanisms for making module use easier. Create a modular application1 Create any number of modules. An MXML-based module file’s root tag is . ActionScript-basedmodules extend either the Module or ModuleBase class.2 Compile each module as if it were an application. You can do this by using the mxmlc command-line compiler orthe compiler built into Adobe Flash Builder.3 Create an Application class. This is typically an MXML file whose root tag is , but it can also bean ActionScript-only application.4 In the Application file, use an tag to load each of the modules. You can also load modules byusing methods of the mx.modules.ModuleLoader and mx.modules.ModuleManager classes. 146USING FLEX 4Application architecture Last updated 11/5/2010Using styles with modulesWhen you set styles on modules, the style properties are set on the local StyleManager. Each module has its owninstance of the IStyleManager2 class. This means that each module can load its own set of styles, and its styles do notnecessarily affect the styles of other modules. After an application finishes loading a module, the module’s styles are merged with the styles of the application. Themodule’s StyleManager walks the chain of parent modules and applications, up to the top-level StyleManager, andmerges its styles with those set on the StyleManagers above it. If during a style merge, a module encounters a style that it already sets on itself, the style is ignored. If the moduleencounters a style not set on itself, the style is added to the merged style definition. The styles set on the StyleManagerthat is closest to the module wins. The following example loads two modules. The main application sets the color and cornerRadius style propertieson the Button control type selector. The modules each set the color property on the Button control type selector. Themerged styles result in the Buttons having a corner radius of 10, with colors set by each module. This shows how stylemerges work. xmlns:fx="http://ns.adobe.com/mxml/2009"xmlns:s="library://ns.adobe.com/flex/spark"xmlns:mx="library://ns.adobe.com/flex/mx">@namespace s "library://ns.adobe.com/flex/spark";s|Button {color:blue;cornerRadius:10;}